We deliver inbound calls to Vapi via an Asterisk PBX. Asterisk dials Vapi's SIP endpoint and includes the caller's number in these headers on every INVITE: P-Asserted-Identity: Remote-Party-ID: X-Caller-Number: +[number] However, {{customer.number}} resolves empty inside the assistant. The dashboard shows our Asterisk trunk identity as the customer number instead of the actual caller. Which header does Vapi use to populate customer.number for calls delivered this way?

Thanks for sharing the details. In Vapi, {{customer.number}} is typically populated from the P-Asserted-Identity header if present; otherwise, it may fall back to the SIP From header. Since your dashboard shows the trunk identity, it seems Asterisk isn’t passing the caller number in a way Vapi recognizes. Can you confirm if your trunk is set to send P-Asserted-Identity with the external caller rather than the PBX’s identity? @LongBeard

@Ramsey We've updated our pre-dial handler to use force on the P-Asserted-Identity header to ensure it overwrites any existing value before the INVITE reaches Vapi. However the dashboard still shows our Asterisk trunk identity as the customer number instead of the actual caller. Our setup is an Asterisk bridge dialing a Vapi SIP number, can you confirm how customer.number is populated for calls delivered this way, and whether there is a specific supported method for passing the caller's number in this scenario?

Got it — if forcing P-Asserted-Identity didn’t fix it, then Vapi is most likely ignoring it in this bridge setup and falling back to the SIP From header. What I’d try next is a simple check: capture the raw INVITE (via sngrep) and make sure the From header is set to the actual caller’s number, not the trunk. In Asterisk bridges, that’s usually what Vapi picks up for customer.number. Also double-check nothing in your trunk/dialplan is rewriting it on the way out, that happens more often than expected. If you want, I can help you step through this and get it working properly, we can sort it out together privately. @LongBeard

We solved it with you suggestion, thanks! @Ramsey